System and Method for Remotely Updating Control Software in a Vehicle With an Electric Drive System

ABSTRACT

A method of remotely updating control software in a heavy-duty vehicle having at least one programmed controller including securing the heavy-duty vehicle; determining that the vehicle is secured; establishing a wireless connection with the heavy-duty vehicle; downloading an updated control software; and updating the heavy-duty vehicle&#39;s control software with the updated control software in response to the determining that the vehicle is secured.

BACKGROUND

1. Field of the Invention

The present invention relates generally to systems and methods forremotely updating control software in a vehicle, and, in particular, avehicle with a hybrid electric drive system.

2. Related Art

Vehicles increasingly rely on software for control functions such asvehicle control, engine control, and control of other vehiclesubsystems. This is especially true for vehicles having electric drivesystems (e.g., Electric Vehicles (“EVs”), Hybrid Electric Vehicles(“HEVs”)) because these vehicles are highly dependent on coordinatedcontrol of their energy sources, generators/electric motors, powerconverters, and energy storage. Heavy-duty vehicles including electricdrive systems rely even more on software for control functions sincethese vehicles typically more complex and include additional subsystemsrequiring control.

New electric drive vehicles and electric drive vehicles first releasedfor testing often require more frequent software updates (e.g., weeklysoftware updates/patches) compared to more mature electric drivevehicles that have been deployed for awhile (e.g., bi-annual softwareupdates/enhancements).

Updating control software on a vehicle can be time-consuming andexpensive. Control software updates on a vehicle may also pose uniquesafety risks. For example, in a standard motor vehicle, a loss ofvehicle control may result in catastrophic loss. Moreover, this risk isexacerbated when the vehicle is a heavy-duty vehicle, especially whenthe heavy-duty vehicle is operated as a common carrier.

Currently, when a vehicle's control software is out of date, either thevehicle must be driven to a service center or a technician must travelto the vehicle in order to update the software on the vehicle. This canbe costly, especially if the technician has to fly to the location ofthe vehicle, and/or if an entire vehicle fleet must be serviced.

Further problems include the requirement of maintaining accurate recordsfor the vehicle and having to accurately monitor the software version ofeach piece of software residing in each vehicle. When vehicle componentsare removed or replaced (e.g., using spare parts), these problems areexacerbated because the software version in the records may notaccurately reflect the software version of the unit actually installedon the vehicle.

Still further, there are limitations to maintaining uniformity ofdeployed software versions dependent upon the number of technicians inthe field and the rate of updating software.

SUMMARY

These problems and/or others are addressed by the systems and methodsfor remotely updating and/or calibrating control software in an electricdrive vehicle of the present invention.

An aspect of the invention involves a method of remotely updatingcontrol software in a heavy-duty vehicle having at least one programmedcontroller. The method includes securing the heavy-duty vehicle;determining that the vehicle is secured; establishing a wirelessconnection with the heavy-duty vehicle; downloading an updated controlsoftware; and updating the heavy-duty vehicle's control software withthe updated control software in response to the determining that thevehicle is secured.

Another aspect of the invention involves a control software updatingdevice in a heavy-duty vehicle having at least one programmedcontroller. The control software updating device includes means fordetermining that the heavy-duty vehicle is secured; a wirelesscommunication module; and a processor configured to update controlsoftware in the at least one programmed controller.

A further aspect of the invention involves a system for remotelyupdating control software in a heavy-duty vehicle having at least oneprogrammed controller. The system includes an indicator configured toindicate that the heavy-duty vehicle is secured; a server configured toprovide updated software; a wireless communication link between theheavy-duty vehicle and the server, the wireless communication linkconfigured to communicate the updated software from the server to theheavy-duty vehicle; and a processor configured to update the heavy-dutyvehicle's control programming using data transmitted from the serveracross the wireless communication link when the heavy-duty vehicle issecured.

Other features and advantages of the present invention will become morereadily apparent to those of ordinary skill in the art after reviewingthe following detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The details of the present invention, both as to its structure andoperation, may be gleaned in part by study of the accompanying drawings,in which like reference numerals refer to like parts, and in which:

FIG. 1 is a network diagram illustrating over-the-air software updatingover a wireless communication network, according to an embodiment of theinvention;

FIG. 2 is a block diagram illustrating an exemplary wirelesscommunication module that may be used in connection with the variousembodiments described herein;

FIG. 3 is a flow diagram illustrating an exemplary method of updatingvehicle software over-the-air;

FIG. 4 is a diagram illustrating an exemplary method of building asoftware version list;

FIG. 5 is a diagram illustrating an exemplary pull method of updatingvehicle software over-the-air;

FIG. 6 is a diagram illustrating an exemplary push method of updatingvehicle software over-the-air; and

FIG. 7 is a diagram illustrating an exemplary direct communicationmethod of updating vehicle software over-the-air.

FIG. 8 is a block diagram illustrating an exemplary computer as may beused in connection with the system(s) to carry out the method(s)described herein.

DETAILED DESCRIPTION

With reference generally to FIGS. 1-8, systems and methods for remotelyupdating vehicle software, and in particular, control software, in ahybrid or electric drive vehicle in accordance with multiple embodimentsof the present invention will be described. In embodiments of theinvention, the systems and methods are for updating control software inany vehicle, especially a heavy duty vehicle, requiring periodic controlsoftware updates. In more preferred embodiments of the invention, thesystems and methods are for updating control software in electric drivevehicles (e.g., HEVs, EVs) requiring periodic control software updates.In most preferred embodiments of the invention, the systems and methodsare for updating control software in heavy-duty electric drive vehicles(e.g., heavy-duty HEVs, heavy-duty EVs) requiring periodic controlsoftware updates. As used herein, a heavy-duty electric drive vehicle isan electric drive vehicle having a gross weight of over 8,500 lbs. Aheavy-duty HEV will typically have a gross weight of over 10,000 lbs.and may include vehicles such as a metropolitan transit bus, a refusecollection truck, a semi tractor trailer, etc.

As used herein, “vehicle software” includes software or modifiablefirmware embedded in the vehicle or component. Also, as used herein,“control software” is software executed by a controller(s) to controlseparate components/systems of the drive train (e.g., Electric VehicleControl Unit (“EVCU”). Further examples of a controller(s) include(s),but are not limited to, a controller associated with one or more of:engine control, energy storage control, generator control, electricmotor control, cooling system control, vehicle control, control of anycomponent that can be flashed over the vehicle communication bus, andcontrol of any component that can be flashed and can communicate acrossthe a vehicle telemetry unit (e.g., Remote Diagnostic Unit (“RDU”)), orany combination thereof.

The systems and methods described herein are applied to a securedvehicle. As used herein, a secured vehicle or “securing a heavy-dutyvehicle” may mean affirmatively securing the vehicle, such as physicallyinhibiting the vehicle or affirmatively indicating that the vehicle issecured. Similarly, “securing a heavy-duty vehicle” may mean passively(constructively) securing the vehicle or otherwise inferring that thevehicle is secured, such as where one condition or state of the vehiclemay be used to determine the vehicle is secured. For example a vehiclemay be constructively “determined” to be secured based on its Location(e.g., parking lot, designated SW update area, vehicle refueling spot,maintenance/repair facility), the Time/Date (e.g., evenings, weekends,times/dates when vehicle is out of service), and/or a vehicleState/Activity associated with being secure. Examples of a vehicleState/Activity associated with being secure include: Vehicle Off,Parked, Refueling, Key removed, Energy Storage disengaged, and Vehicleat a stop (for quick or non-safety related updates, etc.). For thepurposes of this disclosure, “securing the vehicle” is understood as nothaving a rigid definition, but rather should be viewed in light of theupdate to be performed and the understanding that certain updates mayrequire more time and/or vehicle inhibition safeguards than otherupdates.

Updating of the control software in the systems and methods describedherein will largely be described as occurring over a wirelessconnection. As used herein, a “wireless connection” includes, but is notlimited to, WWAN, WLAN, Short range radio, etc. In a preferredembodiment, the wireless connection includes a Wireless Wide AreaNetwork (“WWAN”) such as, but not limited to, cellular, GSM, CDMA,and/or GPRS networks. In an alternative preferred embodiment, thewireless connection includes a Wireless Local Area Network (“WLAN”) andwherein the Access Point (AP) is connected to the backend server via theInternet. In a less preferred embodiment, the wireless connection mayinclude a Peer-to-Peer network (e.g., Short range radio based),buffering the update until the vehicle is secure.

Updating of the control software in the systems and methods describedherein will be described as being performed by a processor configured toupdate heavy-duty vehicle's control programming. As used herein aprocessor configured to update the heavy-duty vehicle's controlprogramming may include a dedicated software update controller onvehicle, a dedicated software update controller on backend server (e.g.,at vehicle manufacturer, fleet management facility, maintenancefacility, etc.), and/or a multipurpose controller on vehicle (e.g.,EVCU, telemetry unit, RDU).

Referring to FIG. 1, a system 100 and method for updating vehiclesoftware, and in particular, control software, in an electric drivevehicle in accordance with an embodiment of the invention will now bedescribed. The system 100 may include a vehicle 110 including anelectric drive system, a controller 120, data storage area 130, andwireless communication module 140. System 100 may further include alocally networked connection to the nodes being programmed (or softwarebeing updated). According to one embodiment this may be a CAN bus.

The controller 120 may include one or more controllers. For example,updated control software may first be received via a central controller,which is different from the one or more programmed controllers that theheavy-duty vehicle control software is directed toward. Further, thecontroller 120 may be one or more of at least one main/central vehiclecontroller, at least one system controller, at least one enginecontroller, at least one remote diagnostics control system, and/or atleast one other vehicle/component controller. An engine controller, asystem controller, and a remote diagnostics control system will each bedescribed in turn below.

Engine Controller

APUs (Auxiliary Power Unit) or energy generation sources may be equippedwith advanced automated controllers which help to minimize fuelconsumption and emissions while facilitating monitoring and diagnosis ofthe engine and generator. Certain APU control systems may automaticallyturn the APU (engine) on and off during vehicle operation. When vehiclepower usage is low and there is sufficient energy in the energy storage(e.g., battery pack) to sustain vehicle operation, the APU controllermay turn the APU off. The APU is then automatically reactivated whenvehicle power requirements increase or the battery energy level beginsto run low. Depending on how the APU is programmed, the vehicle can beoperated as either a “charge sustaining” or a “charge depleting” hybrid.Alternately, when the APU is on, the APU controller may employ a “loadfollowing” technique to tailor APU power output to varying vehicle powerneeds. During acceleration, hill climbing, and other periods of highpower usage, APU power output may automatically be increased to respondto increasing electrical power loads on the generator. When powerrequirements diminish and these loads are relaxed, APU power output maythen be reduced. The controller may also reduce the power output of theAPU instantaneously when energy is added to the system by regenerativebraking, thereby protecting the drive system from “over-voltage”situations. The flexibility offered by an engine controller enablesvehicle power generation to be tailored to different driving cycles oreconomic situations. For example, in areas with severe emissionsproblems or high fuel costs, the controller can be programmed tominimize APU run time and to maximize reliance on battery power.Conversely, the APU can be run more often if it is a higher priority tominimize external battery charging or to extend battery life. For APUsutilizing internal combustion engines, the APU controller may alsomonitor engine health and transmit data on engine temperature, oilpressure, and other key factors to a wireless reporting control unit.The engine controller unit itself may have a form factor of a verysmall, self-contained microprocessor located in the vehicle APUcompartment. Ideally it can be easily diagnosed and removed and replacedby trained service personnel.

System Controllers

Hybrid and drive control software is an integral part of ahybrid-electric vehicle drive system. The vehicle interface is providedby the vehicle controller, which may be based on a high speed automotivemultiplexing system such as J1939. It also provides an interface todisplays and standard vehicle electronics such as GPS. CAN (ControllerArea Network) bus architecture has been greatly simplified over theyears. All major vehicle subsystems (Motive Drive (electric drivemotor), APU, Energy Storage, Vehicle Control, and Accessories) maycommunicate on one single CAN network. This simplifies and improvesvehicle data acquisition and maintenance. All major vehicle subsystemscan then be accessed via one data port. The computerized control networkon the communication bus relies on distribution boxes to monitor, fuse,supply, and/or switch power to high power components.

Remote Diagnostic System (RDS)

A Remote Diagnostic System (RDS) hardware and software package mayprovide a reliable, low-cost conduit between the systems on-board avehicle or in remote locations to operator and maintenance personnel.The RDS comprises a telemetry controller (RDU—Remote Diagnostics Unit)having ability to send commands and set parameters on-board the vehicle.All commands are centrally verified to ensure access by authorizedpersonnel only. The RDS allows the user to control, monitor, diagnose,and analyze advanced vehicles from their desktop computer. For examplean engineer can access important engine data, a technician can displayfault codes, and a manager can monitor fuel economy—all from the sameinterface and without worrying about the connection to the vehicle. Anon-board data processor (ODP) may also be connected to the vehiclesystems (multiplex network), processing all the data into a commonformat and recording the information to an internal flash drive. Timecritical information can be retrieved via the ODP's cellular link.

Each of the abovementioned controllers are programmed to perform theircontrol functions. These controllers are provided for illustration, butare in no way limiting, as there are numerous other controllers on thevehicle.

In operation, in a preferred embodiment, the controller 120 is a centralvehicle controller that may configured to compare current softwareversions with available software versions (e.g., as part of a “pull”technique). As discussed above, examples of a central vehicle controllermay include a main system controller, an engine controller, and a remotediagnostics unit). In an alternative embodiment, the individualcomponent/system directly communicates with the server (e.g., as part ofa “pull” technique) for available software versions. In a furtherembodiment, a version listing, or software library, is utilized and maybe transmitted from the main central controller 120 onto the server 160.Comparison of current software versions with available software versionsmay be done on the server 160 (e.g., as part of a “push” technique).

Controller 120 may be further configured to determine that vehicle 110is secured. Alternately, server 160 may be configured to determine thatvehicle 110 is secured. As discussed throughout this disclosure,determining that vehicle is secured may be accomplished through avariety of means. For example, vehicle 110 may be equipped with sensorsand/or a user interface that expressly indicate that vehicle is secured.Vehicle 110 may communicate data across, for example, a CAN network,from which it may be inferred that the vehicle 110 is secured.Alternately, controller 120/server 160 may receive informationindependently from the vehicle (e.g., time, schedule, 3^(rd) partyinformation) that indicates the vehicle is secured.

Continuing to refer to FIG. 1, wireless communication module 140 is inwireless communication with access point 150 through a wirelesscommunication link. Here, the access point is illustrative only and mayrefer to a variety of wireless communication schemes. Access point 150is in communication with server 160, which is coupled to data storagearea 170, via network 180. The wireless network 180 may be any type ofwireless network, such as, but not limited to, a wireless wide areanetwork (“WWAN”), a wireless local area network (“WLAN”), and/or an IEEE802 wireless network such as an IEEE 802.11 (“WiFi”) network. Thewireless network 180 and/or wireless communication link may be partwireless, part wired (e.g., WLAN and Internet).

Wireless communication between the vehicle 110 and the server 160 ispreferably via the RDU (or other onboard telemetry controller) and thewireless connection with the server 160 is via a WWAN (e.g., Cell, GPRS,CDMA, GSM). In an alternative embodiment, wireless connection with theserver 160 is via WLAN communicatively coupled to the Internet. In afurther embodiment, wireless connection with the server 160 is viaPeer-to-Peer communication, which is stored or buffered until thevehicle is secured.

With reference to FIG. 2, an embodiment of a wireless communicationmodule 140 includes an antenna 208 for wireless transmission of data toand from controller 120. In alternative embodiments, other wirelesscommunication devices and/or architectures may also be used, as will beclear to those skilled in the art. In the illustrated embodiment,wireless communication module 140 is used for communication of dataand/or audio communications to and from the vehicle 110.

Wireless communication device or module 140 may comprise a multiplexor254 connected to antenna 208, a low noise amplifier (“LNA”) 256, a poweramplifier (“PA”) 258, and a modulation circuit 260 which is connected tobaseband processor 262. In the wireless communication device 140, radiofrequency (“RF”) signals are transmitted and received by antenna 208.Multiplexor 254 acts as a switch, coupling antenna 208 between thetransmit and receive signal paths. In the receive path, received RFsignals are coupled from a multiplexor 254 to LNA 256. LNA 256 amplifiesthe received RF signal and couples the amplified signal to ademodulation portion of the modulation circuit 260.

Typically modulation circuit 260 will combine a demodulator andmodulator in one integrated circuit (“IC”). The demodulator andmodulator can also be separate components. The demodulator strips awaythe RF carrier signal leaving a base-band receive signal, which is sentfrom the demodulator output to the base-band processor 262.

The baseband processor 262 is also communicatively coupled with thecontroller 120. The controller 120 has access to a data storage area130, as illustrated in FIG. 1, and is configured to execute instructions(i.e., computer programs or software) that can be stored in the datastorage area 130. Software upgrades are received from the basebandprocessor 262 and may be stored in the data storage area 130, a bufferarea, or other data storage area where the software upgrades areinstalled and/or executed. Such software upgrades, when executed,control functions such as vehicle control, engine control, and controlof other vehicle systems.

Referring to FIG. 3, an exemplary method 300 of updating vehiclesoftware over-the-air will now be described. Although the steps in themethod 300 are described in a particular order, in alternativeembodiments, the steps are performed in different orders than those setforth as illustrated. For example, but not by way of limitation, the“securing step” may be the first step, second step, or other numberedstep than that indicated below. Further, the method 300 may have othernumbers of steps (e.g., additional steps, fewer steps) or differentsteps than those indicated below. Also for example, method 300 mayinclude a method of remotely updating control software in a heavy-dutyvehicle having at least one programmed controller, the method comprisingsecuring the heavy-duty vehicle, determining that the vehicle issecured, establishing a wireless connection with the heavy-duty vehicle,downloading an updated control software, and updating the heavy-dutyvehicle's control software with the updated control software in responseto the determining that the vehicle is secured.

According to one embodiment, at step 310, a determination is made onwhether the software version on the vehicle 110 needs to bereplaced/upgraded (hereinafter “updated”). For example, the method maycompare an installed version of controller software with a later orlatest version of control software. Thus, when there is a newer versionavailable than what is installed in the vehicle, the older version canbe replaced with the newer version. Preferably, when a descriptivesoftware naming convention is used, the comparison may only involvecomparing the file names of the software (e.g., <filename_v1>,<filename_v2>).

This version check/determination may include a prioritization of thecomponents/systems to be checked. In particular, the versioncheck/determination may check each software file in a predetermined,prioritized order, or check priority software files more often. Forexample, safety related and/or vehicle performance relatedcomponents/systems may have priority over other components/systems.Likewise, priority may be given to units/systems that are moresusceptible to updates. Accordingly, the software files associated withthe prioritized components/systems may be treated as priority software.Alternately, this version check/determination may set a predeterminedschedule of how often the components'/systems' software gets checked.For example, safety related, performance related, and/or items likely tobe updated frequently may be scheduled to be checked more often.

According to one embodiment, the vehicle 110/server 160 may checkfor/receive updates continuously, regularly, and/or real time (withoutwaiting for the vehicle to be secured), but wait to be secured prior toexecuting the update. The vehicle 110/server 160 may compare whatversions the vehicle 110 has with what versions are available. Accordingto one embodiment, whatever system/component has access to the wirelesscommunication module may perform the check.

According to one embodiment, this determination may be initiated by thevehicle 110 or from onboard the vehicle. For example FIG. 5 illustratesan exemplary “pull technique” that may initiated from a controlleronboard the vehicle. Alternately, this determination may be initiated bythe software provider (e.g., vehicle manufacturer) or otherwise fromoffboard the vehicle. For example FIG. 6 illustrates an exemplary “pushtechnique” that may initiated from a server function offboard thevehicle.

As shown in FIG. 4, in an embodiment where a version listing or softwarelibrary is used/built, a polling or current software version request isbroadcasted by the controller 120 to the units/systems/components ofinterest, the returned software versions are then received and recordedby the controller 120. This data may be formatted into a machinereadable current software version list or software library. According toone embodiment, the latest available software versions may be comparedwith the software library, and after upgrade is completed, the softwarelibrary may be again updated. For illustration, in the example shown,Units/Components/Systems #1, 2, 3, 4 indicate to the controller 120 thatversions 1.1, 1.6, 1.2, and 1.4 are currently in use. In a preferredembodiment, the version listing or software library is built at thefirst use of the vehicle. In an alternative embodiment the polling orcurrent software version request is broadcasted at vehicle start up.Building the version list at start up can address the possibility ofcomponents being replaced with components having a different softwareversion during, for example, periods when the vehicle is offline.

With reference to FIG. 5, an embodiment of a “pull” technique forover-the-air software upgrades will be described. The controller 120sends a request to the remote server 160 for the latest softwareversions and the server 160 reports back that versions 1.1, 1.7, 1.2,and 1.5 are the latest available software versions. Controller maycompare the latest available version with those installed on thevehicle. According to one embodiment, a version list/library may havebeen previously build and stored, as described above, for comparison. Inthe “pull” technique example of FIG. 5, controller 120 determines thatthe software versions in Units/Components/Systems #1, 3 are current andthat the software versions in Units/Components/Systems #2, 4 are out ofdate. Accordingly, the controller 120 requests software updates forUnits/Components/Systems #2, 4, and these versions are downloaded fromthe server 160 to the controller 120.

With reference to FIG. 6, an embodiment of a “push” technique forover-the-air software upgrades will be described. The remote server 160sends a request to the controller 120 for the latest software versionsand the controller 120 requests the same from theUnits/Components/Systems #1, 2, 3, 4. The Units/Components/Systems #1,2, 3, 4 report back that versions 1.1, 1.6, 1.2, and 1.4 are the latestavailable software versions, and this information is transmitted fromthe controller 120 to the server 160. Alternately, this informationmaybe previously obtained as part of building a version list, and may betransmitted from controller 120 to server 160. As exemplified, theserver 160 may then determine whether any of these software versions areout-of-date, and, if so, sends the latest versions to the controller 120for updating the software of the appropriate

Units/Components/Systems.

With reference to FIG. 7, in an alternative embodiment, the individualUnits/Components/Systems communicate directly with the server 160 via aRDU. This is more appropriate in a vehicle that does not have a centralcontroller and where the individual Units/Components/Systems use anonboard telemetry unit merely as a communications gateway. Asexemplified, the server 160 requests the software version for eachUnits/Components/Systems directly from the Units/Components/Systems, andthe Units/Components/Systems report back the current software version ofthe Units/Components/Systems. The server 160 then determines whether anyof these software versions are out-of-date, and, if so, sends the latestversions to the controller 120 for updating the software of theappropriate Units/Components/Systems.

At step 320, the updated vehicle software version iscommunicated/downloaded to the vehicle via wireless connection. Asdiscussed above the wireless connection or link may include WWAN, WLAN,Short range radio, etc., and may be integrated with the Internet and anaccess point. The updated vehicle software version communicated to thevehicle may be stored in a buffer/intermediate storage pending securingof the vehicle. According to one embodiment, the updated vehiclesoftware version may be downloaded to the buffer whenever a goodconnection is established, and installed later, when the vehicle 110 issecure.

According to one embodiment, the method 300 may include synchronizationbetween download and update. For example, the method may first finishits over-the-air download, make additional determinations (i.e., checkintegrity of the updated version of control software, configure datastorage 130 to be flashed, etc.), then when everything is fine, proceedto update, thus avoiding streaming flash. Synchronization betweendownload and update helps avoid data collisions and installing corrupteddata.

At step 330, confirmation/determination is made that the vehicle 110 issecured. Securing the vehicle 110 before and during the vehicle softwareupdate is important for safety reasons since some vehicle softwareupdates affect vehicle operation. Determining that the heavy-dutyvehicle is secured may include receiving a primary indication from thevehicle 110 that the vehicle 110 is secured. As discussed above, thevehicle may be secured in a variety of ways. For example, the vehiclemay be “secured” by placing the vehicle 110 in a “secure” area.Physically secure areas may include, but not by way of limitation, thevehicle's designated parking space in a motor pool yard, a designatedover-the-air software update location, a maintenance facility/depot, andany other area where there is an awareness of the update and anexpectation that the vehicle will not be operated during the updateperiod.

The vehicle 110 may be expressly identified as being in a securelocation. For example, an operator may manually report that the vehicle110 is secured. Also, the vehicle 110 may report itself as securedthrough a short range radio or RFID such as where the vehicle 110 mustbe physically located in the secure area for the self-reporting totrigger and/or operate. With a vehicle 110 having GPS and telemetriccapability, such as a RDU-equipped metropolitan transit bus, a remoteuser/server 160 may also inquire as to the vehicle's location, and uponan acceptable response (i.e., in its designated parking spot), theremote user/server 160 may initiate the software update over-the-air.This embodiment is ideal for a systems integrator desiring toefficiently update its deployed fleet while maintaining positive controlover the updates.

According to another embodiment, depending on the degree of the updateand the time required, the vehicle 110 may be determined to be “secure”for update upon determining that the vehicle 110 is not in motion, orwill not be in motion for a sufficient amount of time. For example,where the software update will not affect the safety of the vehicle 110,and where the time to update the software is of orders of magnitude lessthan the time to start a stopped vehicle, the vehicle 110 may bedetermined to be secured by virtue of its being stopped. Similarly,during certain refueling operations (e.g., fuel cell powered hybrids)the refueling process may provide ample time and securing for certainupdates.

According to another embodiment, the vehicle 110 is indicated/determinedas being “secured” by a secondary indication such as, but not limitedto, an indication based on the location of the heavy-duty vehicle, astate or an activity associated with the vehicle being shut down (e.g.,override information associated with the vehicle being serviced), astate or an activity associated with the vehicle being detained (e.g.,refueling information), and time/date limitations. For example, thevehicle 110 may be considered “secured” when there's no signal from thevehicle ignition, when the vehicle/engine control unit is identified asbeing in a “standby” mode, when fault conditions are reported such thatthe vehicle cannot be in operation, and when only GPS being reported bythe vehicle telemetry system (i.e., no other vehicle systems arereporting across the CAN network). Similarly, vehicle 110 may beconsidered “secured” overnight, weekends, or any other time period thatthe vehicle is scheduled as off-duty or otherwise not being operated.Additionally, vehicle 110 may be considered “secured” based oncombinations of time and location information.

At step 340, the control software in vehicle 110 is updated responsiveto the determination that the vehicle is secured. As discussed above,the update may be performed via a central controller or the unit/systemitself Typically, the update may comprise flashing the unit's/system'sprogrammable memory.

Also, the update may be integrated into the download function, such thatdownloading and the updating are substantially the same function. Thismay entail downloading directly to the final memory location. In thiscase, however, additional steps such as reconfiguring theunit/system/vehicle registers to reflect the change and/or some form ofintegrity check may also be included.

In an embodiment of the invention, self checks/integrity checks of thenew version may occur prior to installing/executing the new version. Forexample, to determine/indicate the integrity of software received, theupdated software may be verified prior to installation using standardchecksum, mdssum, cyclic redundancy check (CRC), forward errorcorrection (FEC) techniques. Also, the self checks/integrity checks mayinclude a mechanism for repairing corrupted data prior to install. Forexample, this may include reconstructing the file using the FEC, orretransmitting the file in response to detecting corruption. If the selfchecks/integrity checks determine a fault with the new version, the oldsoftware version may be kept and the download may be performed again.

As discussed above, updating the software may include factoring in thetime it takes to install the new version. For example, a quick updatemay not require the same level of securing as a longer update. Updatingthe software may also include factoring whether the update will affectthe safe operation of the vehicle. According to one embodiment, thevehicle may be “locked” in the “secure” state (i.e., being preventedfrom operating) until an update is complete.

Updating the software may include first conditioning/configuring thecomponent/system to receive the new software prior to install. Forexample, when the RDU (or other central controller) is responsible formanaging the software update, the RDU may recognize and command anyconfigurations necessary on the end-recipient unit toreceive/install/flash the new software update.

According to one embodiment, one or more reports may be sent by thevehicle 110 when the software updated is completed. For example, thereports may be sent to the vehicle operator, to provider of the softwareupgrade, and/or to the vehicle manufacturer/integrator Additionally, theone or more report may include transmitting a completion report back tothe server 160, reporting on which vehicle 110 updates are completedand/or which updates failed. This reporting may also include indicationsonboard the vehicle 110 to an operator. For example, they may indicate:(1) that a download trigger has been detected (e.g., there is newsoftware in the buffer and the vehicle is now secured, new updatesavailable, etc.), (2) initiation of download from buffer, and (3) thatthe download is complete. This onboard reporting may also include anoption allowing the operator to initiate or to override the download, orprovide warning not attempt to operate the vehicle 110 until thedownload is complete.

The systems and methods for remotely updating vehicle softwareover-the-air are advantageous in that the method(s) may besimultaneously performed on a fleet of vehicles at a single time andsoftware updates can be rapidly performed in an efficient,cost-effective, and safe manner.

FIG. 8 is a block diagram illustrating an exemplary computer system 550that may be used in connection with the various embodiments describedherein. For example, the computer system 550 (or various components orcombinations of components of the computer system 550) may be used inconjunction with the controller 120 and/or other controllers describedherein to control the functions described herein. However, othercomputer systems and/or architectures may be used, as will be clear tothose skilled in the art.

The computer system 550 preferably includes one or more processors, suchas processor 552. Additional processors may be provided, such as anauxiliary processor to manage input/output, an auxiliary processor toperform floating point mathematical operations, a special-purposemicroprocessor having an architecture suitable for fast execution ofsignal processing algorithms (e.g., digital signal processor), a slaveprocessor subordinate to the main processing system (e.g., back-endprocessor), an additional microprocessor or controller for dual ormultiple processor systems, or a coprocessor. Such auxiliary processorsmay be discrete processors or may be integrated with the processor 552.

The processor 552 is preferably connected to a communication bus 554.The communication bus 554 may include a data channel for facilitatinginformation transfer between storage and other peripheral components ofthe computer system 550. The communication bus 554 further may provide aset of signals used for communication with the processor 552, includinga data bus, address bus, and control bus (not shown). The communicationbus 554 may comprise any standard or non-standard bus architecture suchas, for example, bus architectures compliant with industry standardarchitecture (“ISA”), extended industry standard architecture (“EISA”),Micro Channel Architecture (“MCA”), peripheral component interconnect(“PCI”) local bus, or standards promulgated by the Institute ofElectrical and Electronics Engineers (“IEEE”) including IEEE 488general-purpose interface bus (“GPIB”), IEEE 696/S-100, and the like.

Computer system 550 preferably includes a main memory 556 and may alsoinclude a secondary memory 558. The main memory 556 provides storage ofinstructions and data for programs executing on the processor 552. Themain memory 556 is typically semiconductor-based memory such as dynamicrandom access memory (“DRAM”) and/or static random access memory(“SRAM”). Other semiconductor-based memory types include, for example,synchronous dynamic random access memory (“SDRAM”), Rambus dynamicrandom access memory (“RDRAM”), ferroelectric random access memory(“FRAM”), and the like, including read only memory (“ROM”).

The secondary memory 558 may optionally include a hard disk drive 560and/or a removable storage drive 562, for example a floppy disk drive, amagnetic tape drive, a compact disc (“CD”) drive, a digital versatiledisc (“DVD”) drive, etc. The removable storage drive 562 reads fromand/or writes to a removable storage medium 564 in a well-known manner.Removable storage medium 564 may be, for example, a floppy disk,magnetic tape, CD, DVD, etc.

The removable storage medium 564 is preferably a computer readablemedium having stored thereon computer executable code (i.e., software)and/or data. The computer software or data stored on the removablestorage medium 564 is read into the computer system 550 as electricalcommunication signals 578.

In alternative embodiments, secondary memory 558 may include othersimilar means for allowing computer programs or other data orinstructions to be loaded into the computer system 550. Such means mayinclude, for example, an external storage medium 572 and an interface570. Examples of external storage medium 572 may include an externalhard disk drive or an external optical drive, or and externalmagneto-optical drive.

Other examples of secondary memory 558 may include semiconductor-basedmemory such as programmable read-only memory (“PROM”), erasableprogrammable read-only memory (“EPROM”), electrically erasable read-onlymemory (“EEPROM”), or flash memory (block oriented memory similar toEEPROM). Also included are any other removable storage units 572 andinterfaces 570, which allow software and data to be transferred from theremovable storage unit 572 to the computer system 550.

Computer system 550 may also include a communication interface 574. Thecommunication interface 574 allows software and data to be transferredbetween computer system 550 and external devices (e.g. techniciandiagnostic laptops), networks, or information sources. For example,computer software or executable code may be transferred to computersystem 550 from a network server via communication interface 574.Examples of communication interface 574 include a modem, a networkinterface card (“NIC”), a communications port, a PCMCIA slot and card,an infrared interface, and an IEEE 1394 fire-wire, just to name a few.

Communication interface 574 preferably implements industry promulgatedprotocol standards, such as Ethernet IEEE 802 standards, Fiber Channel,digital subscriber line (“DSL”), asynchronous digital subscriber line(“ADSL”), frame relay, asynchronous transfer mode (“ATM”), integrateddigital services network (“ISDN”), personal communications services(“PCS”), transmission control protocol/Internet protocol (“TCP/IP”),serial line Internet protocol/point to point protocol (“SLIP/PPP”), andso on, but may also implement customized or non-standard interfaceprotocols as well.

Software and data transferred via communication interface 574 aregenerally in the form of electrical communication signals 578. Thesesignals 578 are preferably provided to communication interface 574 via acommunication channel 576. Communication channel 576 carries signals 578and can be implemented using a variety of wired or wirelesscommunication means including wire or cable, fiber optics, conventionalphone line, cellular phone link, wireless data communication link, radiofrequency (RF) link, or infrared link, just to name a few.

Computer executable code (i.e., computer programs or software) is storedin the main memory 556 and/or the secondary memory 558. Computerprograms can also be received via communication interface 574 and storedin the main memory 556 and/or the secondary memory 558. Such computerprograms, when executed, enable the computer system 550 to perform thevarious functions of the present invention as previously described.

In this description, the term “computer readable medium” is used torefer to any media used to provide computer executable code (e.g.,software and computer programs) to the computer system 550. Examples ofthese media include main memory 556, secondary memory 558 (includinghard disk drive 560, removable storage medium 564, and external storagemedium 572), and any peripheral device communicatively coupled withcommunication interface 574 (including a network information server orother network device). These computer readable mediums are means forproviding executable code, programming instructions, and software to thecomputer system 550.

In an embodiment that is implemented using software, the software may bestored on a computer readable medium and loaded into computer system 550by way of removable storage drive 562, interface 570, or communicationinterface 574. In such an embodiment, the software is loaded into thecomputer system 550 in the form of electrical communication signals 578.The software, when executed by the processor 552, preferably causes theprocessor 552 to perform the inventive features and functions previouslydescribed herein.

Various embodiments may also be implemented primarily in hardware using,for example, components such as application specific integrated circuits(“ASICs”), or field programmable gate arrays (“FPGAs”). Implementationof a hardware state machine capable of performing the functionsdescribed herein will also be apparent to those skilled in the relevantart. Various embodiments may also be implemented using a combination ofboth hardware and software.

Furthermore, those of skill in the art will appreciate that the variousillustrative logical blocks, modules, circuits, and method stepsdescribed in connection with the above described figures and theembodiments disclosed herein can often be implemented as electronichardware, computer software, or combinations of both. To clearlyillustrate this interchangeability of hardware and software, variousillustrative components, blocks, modules, circuits, and steps have beendescribed above generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular application and design constraints imposed on the overallsystem. Skilled persons can implement the described functionality invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the invention. In addition, the grouping of functions within amodule, block, circuit or step is for ease of description. Specificfunctions or steps can be moved from one module, block or circuit toanother without departing from the invention.

Moreover, the various illustrative logical blocks, modules, and methodsdescribed in connection with the embodiments disclosed herein can beimplemented or performed with a general purpose processor, a digitalsignal processor (“DSP”), an ASIC, FPGA or other programmable logicdevice, discrete gate or transistor logic, discrete hardware components,or any combination thereof designed to perform the functions describedherein. A general-purpose processor can be a microprocessor, but in thealternative, the processor can be any processor, controller,microcontroller, or state machine. A processor can also be implementedas a combination of computing devices, for example, a combination of aDSP and a microprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration.

Additionally, the steps of a method or algorithm described in connectionwith the embodiments disclosed herein can be embodied directly inhardware, in a software module executed by a processor, or in acombination of the two. A software module can reside in RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, harddisk, a removable disk, a CD-ROM, or any other form of storage mediumincluding a network storage medium. An exemplary storage medium can becoupled to the processor such the processor can read information from,and write information to, the storage medium. In the alternative, thestorage medium can be integral to the processor. The processor and thestorage medium can also reside in an ASIC.

The above figures may depict exemplary configurations for the invention,which is done to aid in understanding the features and functionalitythat can be included in the invention. The invention is not restrictedto the illustrated architectures or configurations, but can beimplemented using a variety of alternative architectures andconfigurations. Additionally, although the invention is described abovein terms of various exemplary embodiments and implementations, it shouldbe understood that the various features and functionality described inone or more of the individual embodiments with which they are described,but instead can be applied, alone or in some combination, to one or moreof the other embodiments of the invention, whether or not suchembodiments are described and whether or not such features are presentedas being a part of a described embodiment. Thus the breadth and scope ofthe present invention, especially in the following claims, should not belimited by any of the above-described exemplary embodiments.

Terms and phrases used in this document, and variations thereof, unlessotherwise expressly stated, should be construed as open ended as opposedto limiting. As examples of the foregoing: the term “including” shouldbe read as mean “including, without limitation” or the like; the term“example” is used to provide exemplary instances of the item indiscussion, not an exhaustive or limiting list thereof, and adjectivessuch as “conventional,” “traditional,” “standard,” “known” and terms ofsimilar meaning should not be construed as limiting the item describedto a given time period or to an item available as of a given time, butinstead should be read to encompass conventional, traditional, normal,or standard technologies that may be available or known now or at anytime in the future. Likewise, a group of items linked with theconjunction “and” should not be read as requiring that each and everyone of those items be present in the grouping, but rather should be readas “and/or” unless expressly stated otherwise. Similarly, a group ofitems linked with the conjunction “or” should not be read as requiringmutual exclusivity among that group, but rather should also be read as“and/or” unless expressly stated otherwise. Furthermore, although item,elements or components of the disclosure may be described or claimed inthe singular, the plural is contemplated to be within the scope thereofunless limitation to the singular is explicitly stated. The presence ofbroadening words and phrases such as “one or more,” “at least,” “but notlimited to” or other like phrases in some instances shall not be read tomean that the narrower case is intended or required in instances wheresuch broadening phrases may be absent.

1. A method of remotely updating control software in a heavy-dutyvehicle having at least one programmed controller, the methodcomprising: securing the heavy-duty vehicle; determining that thevehicle is secured; establishing a wireless connection with theheavy-duty vehicle; downloading an updated control software; and,updating the heavy-duty vehicle's control software with the updatedcontrol software in response to the determining that the vehicle issecured.
 2. The method of claim 1, wherein the heavy-duty vehicleincludes an electric drive system.
 3. The method of claim 1, furthercomprising comparing an installed version of controller software with alater version of control software.
 4. The method of claim 3, wherein thecomparing the installed version of control software is initiated fromonboard the heavy-duty vehicle.
 5. The method of claim 3, wherein thecomparing the installed version of control software is initiated fromoffboard the heavy-duty vehicle.
 6. The method of claim 1, wherein thesecuring the heavy-duty vehicle comprises physically securing theheavy-duty vehicle.
 7. The method of claim 1, wherein the determiningthat the heavy-duty vehicle is secured comprises receiving a primaryindication that the vehicle is secured.
 8. The method of claim 1,wherein the determining that the heavy-duty vehicle is secured comprisesreceiving a secondary indication, which is associated with a conditionof the vehicle that is also associated with the vehicle being secured.9. The method of claim 8, wherein the secondary indication comprises alocation of the heavy-duty vehicle; and, wherein the determining thatthe heavy-duty vehicle is secured is based on the location of theheavy-duty vehicle.
 10. The method of claim 8, wherein the secondaryindication comprises a state or an activity associated with the vehiclebeing shut down.
 11. The method of claim 10, wherein the state or theactivity associated with the vehicle being shut down comprises a time ora date information associated with the vehicle being out-of-service. 12.The method of claim 10, wherein the state or the activity associatedwith the vehicle being shut down comprises an override informationassociated with the vehicle being serviced.
 13. The method of claim 8,wherein the secondary indication comprises a state or an activityassociated with the vehicle being detained.
 14. The method of claim 13,wherein the state or the activity associated with the vehicle beingdetained comprises a refueling information.
 15. The method of claim 1,wherein the establishing the wireless connection with the heavy-dutyvehicle comprises establishing the wireless connection with an accesspoint communicatively coupled to the Internet.
 16. The method of claim1, wherein the downloading the updated control software and the updatingthe heavy-duty vehicle's control software are substantially the samefunction.
 17. The method of claim 1, wherein the downloading the updatedcontrol software further comprises receiving and storing a latestversion of control software prior to the determining that the vehicle issecured.
 18. The method of claim 1, wherein the downloading the updatedcontrol software comprises confirming the integrity of the updatedcontrol software transmission.
 19. The method of claim 1, wherein theupdating the heavy-duty vehicle's control software comprises confirmingthe integrity of the updated control software.
 20. The method of claim1, wherein the downloading the updated control software comprisesdownloading the updated control software via a central controllerdifferent from the at least one programmed controller; and, wherein theupdating the heavy-duty vehicle's control software comprises the centralcontroller configuring the at least one programmed controller to receivethe updated control software.
 21. The method of claim 1, furthercomprising limiting functionality of the heavy-duty vehicle during theupdating the heavy-duty vehicle's control software.
 22. A controlsoftware updating device in a heavy-duty vehicle having at least oneprogrammed controller, the control software updating device comprising:means for determining that the heavy-duty vehicle is secured; a wirelesscommunication module configured to receive an updated control software;a processor configured to update control software in the at least oneprogrammed controller responsive to determining that the heavy-dutyvehicle is secured.
 23. A system for remotely updating control softwarein a heavy-duty vehicle having at least one programmed controller, thesystem comprising: an indicator configured to indicate that theheavy-duty vehicle is secured; a server configured to provide updatedsoftware; a wireless communication link between the heavy-duty vehicleand the server, the wireless communication link configured tocommunicate the updated software from the server to the heavy-dutyvehicle; a processor configured to update the heavy-duty vehicle'scontrol programming using data transmitted from the server across thewireless communication link when the heavy-duty vehicle is secured. 24.The system of claim 23, wherein the wireless communication link betweenthe heavy-duty vehicle and the server includes an intermediate networkcomprising at least a WLAN and Internet.
 25. The system of claim 23,wherein the at least one programmed controller includes the processor.26. The system of claim 25, further including a telemetry systemcontroller other than the at least one programmed controller includingthe processor.